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THE TFTP PROTOCOL (REVISION 2) 


Summary 
TFTP is a very simple protocol used to transfer files. It is from 
this that its name comes, Trivial File Transfer Protocol or TFTP. Each 


nonterminal packet is acknowledged separately. This document describes 
the protocol and its types of packets. The document also explains the 


reasons behind some of the design decisions. 
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1. Purpose 

TFTP is a simple protocol to transfer files, and therefore was named 
the Trivial File Transfer Protocol or TFTP. It has been implemented on 
top of the Internet User Datagram protocol (UDP or Datagram) [2] so it 
may be used to move files between machines on different networks 
implementing UDP. (This should not exlude the possibility of 
implementing TFTP on top of other datagram protocols.) It is designed 
to be small and easy to implement. Therefore, it lacks most of the 
features of a regular FTP. The only thing it can do is read and write 
files (or mail) from/to a remote server. It cannot list directories, 
and currently has no provisions for user authentication. In common with 
other Internet protocols, it passes 8 bit bytes of data. 
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Three modes of transfer are currently supported: netascii ; octet , 

raw 8 bit bytes; mail, netascii characters sent to a user rather than a 


file. Additional modes can be defined by pairs of cooperating hosts. 
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This is ascii as defined in "USA Standard Code for Information 
Interchange" [1] with the modifications specified in "Telnet Protocol 
Specification" [3]. Note that it is 8 bit ascii. The term "netascii" 


will be used throughout this document to mean this particular version of 
ascii. 
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This replaces the "binary" mode of previous versions of this 


2. Overview of the Protocol 

Any transsfer begins with a request to read or write a file, which also 
serves to request a connection. If the server grants the request, the 
connection is opened and the file is sent in fixed length blocks of 512 
bytes. Each data packet contains one block of data, and must be 
acknowledged by an acknowledgment packet before the next packet can be 


sent. A data packet of less than 512 bytes signals termination of a 


transfer. If a packet gets lost in the network, the intended recipient 
will timeout and may retransmit his last packet (which may be data or an 
acknowledgment), thus causing the sender of the lost packet to 
retransmit that lost packet. The sender has to keep just one packet on 
hand for retransmission, since the lock step acknowledgment guarantees 


that all older packets have been received. Notice that both machines 


involved ina transfer are considered senders and receivers. One sends 
data and receives acknowledgments, the other sends acknowledgments and 


receives data. 


Most errors cause termination of the connection. An error is 
signalled by sending an error packet. This packet is not acknowledged, 
and not retransmitted (i.e., a TFTP server or user may terminate after 


sending an error message), so the other end of the connection may not 


get it. Therefore timeouts are used to detect such a termination when 
the error packet has been lost. Errors are caused by three types of 
events: not being able to satisfy the request (e.g., file not found, 


access violation, or no such user), receiving a packet which cannot be 


explained by a delay or duplication in the network (e.g. an incorrectly 


formed packet), and losing access to a necessary resource (e.g., disk 


full or access denied during a transfer). 


TFTP recognizes only one error condition that does not cause 
termination, the source port of a received packet being incorrect. In 


this case, an error packet is sent to the originating host. 


This protocol is very restrictive, in order to simplify 
implementation. For example, the fixed length blocks make allocation 
straight forward, and the lock step acknowledgement provides flow 


control and eliminates the need to reorder incoming data packets. 


3. Relation to other Protocols 
As mentioned TFTP is designed to be implemented on top of the Datagram 
protocol. Since Datagram is implemented on the Internet protocol, 


packets will have an Internet header, a Datagram header, and a TFTP 


header. Additionally, the packets may have a header (LNI, ARPA header, 
etc.) to allow them through the local transport medium. As shown in 
Figure 3-1, the order of the contents of a packet will be: local medium 


header, if used, Internet header, Datagram header, TFTP header, followed 
by the remainder of the TFTP packet. (This may or may not be data 
depending on the type of packet as specified in the TFTP header.) TFTP 
does not specify any of the values in the Internet header. On the other 
hand, the source and destination port fields of the Datagram header (its 
format is given in the appendix) are used by TFTP and the length field 


reflects the size of the TFTP packet. The transfer identifiers (TID’s) 


used by TFTP are passed to the Datagram layer to be used as ports; 
therefore they must be between 0 and 65,535. The initialization of 


TID's is discussed in the section on initial connection protocol. 


The TFTP header consists of a 2 byte opcode field which indicates the 
packet’s type (e.g., DATA, ERROR, etc.) These opcodes and the formats 
of the various types of packets are discussed further in the section on 
TFTP packets. 


Figure 3-1: Order of Headers 


4. Initial Connection Protocol 

A transfer is established by sending a request (WRQ to write onto a 
foreign file system, or RRQ to read from it), and receiving a positive 
reply, an acknowledgment packet for write, or the first data packet for 
read. In general an acknowledgment packet will contain the block number 
of the data packet being acknowledged. Each data packet has associated 
with it a block number; block numbers are consecutive and begin with 
one. Since the positive response to a write request is an 
acknowledgment packet, in this special case the block number will be 
zero. (Normally, since an acknowledgment packet is acknowledging a data 
packet, the acknowledgment packet will contain the block number of the 


data packet being acknowledged.) If the reply is an error packet, then 


the request has been denied. 


In order to create a connection, each end of the connection chooses a 
TID for itself, to be used for the duration of that connection. The 
TID’s chosen for a connection should be randomly chosen, so that the 
probability that the same number is chosen twice in immediate succession 
is very low. Every packet has associated with it the two TID’s of the 
ends of the connection, the source TID and the destination TID. These 
TID’s are handed to the supporting UDP (or other datagram protocol) as 
the source and destination ports. A requesting host chooses its source 
TID as described above, and sends its initial request to the known TID 
69 decimal (105 octal) on the serving host. The response to the 
request, under normal operation, uses a TID chosen by the server as its 
source TID and the TID chosen for the previous message by the requestor 
as its destination TID. The two chosen TID’s are then used for the 


remainder of the transfer. 


As an example, the following shows the steps used to establish a 
connection to write a file. Note that WRQ, ACK, and DATA are the names 
of the write request, acknowledgment, and data types of packets 
respectively. The appendix contains a similar example for reading a 
file. 


1. Host A sends a "WRQ" to host B with source= A's TID, 
destination= 69. 


2. Host B sends a "ACK" (with block number= 0) to host A with 
source= B’s TID, destination= A’s TID. 


At this point the connection has been established and the first data 
packet can be sent by Host A with a sequence number of 1. In the next 
step, and in all succeeding steps, the hosts should make sure that the 
source TID matches the value that was agreed on in steps 1 and 2. Ifa 
source TID does not match, the packet should be discarded as erroneously 
sent from somewhere else. An error packet should be sent to the source 
of the incorrect packet, while not disturbing the transfer. 

This can be done only if the TFTP in fact receives a packet with an 
incorrect TID. If the supporting protocols do not allow it, this 


particular error condition will not arise. 


The following example demonstrates a correct operation of the protocol 


in which the above situation can occur. Host A sends a request to host 


B. Somewhere in the network, the request packet is duplicated, and as a 
result two acknowledgments are returned to host A, with different TID’s 
chosen on host B in response to the two requests. When the first 
response arrives, host A continues the connection. When the second 
response to the request arrives, it should be rejected, but there is no 
reason to terminate the first connection. Therefore, if different TID’s 
are chosen for the two connections on host B and host A checks the 
source TID's of the messages it receives, the first connection can be 


maintained while the second is rejected by returning an error packet. 


5. TFTP Packets 
TFTP supports five types of packets, all of which have been mentioned 


above: 


opcode operation 


il Read request (RRQ) 

2 Write request (WRQ) 
3 Data (DATA) 

4 Acknowledgment (ACK) 
5 Error (ERROR) 


The TFTP header of a packet contains the opcode associated with that 
packet. 


Figure 5-1: RRQ/WRQ packet 


RRQ and WRQ packets (opcodes 1 and 2 respectively) have the format 
shown in Figure 5-1. The file name is a sequence of bytes in netascii 
terminated by a zero byte. The mode field contains the string 
"netascii", "octet", or "mail" (or any comibnation of upper and lower 
case, such as "NETASCII", NetAscii", etc.) in netascii indicating the 
three modes defined in the protocol. A host which receives netascii 
mode data must translate the data to its own format. Octet mode is used 
to transfer a file that is in the 8-bit format of the machine from which 
the file is being transferred. It is assumed that each type of machine 


has a single 8-bit format that is more common, and that that format is 


chosen. For example, on a DEC-20, a 36 bit machine, this is four 8-bit 
bytes to a word with four bits of breakage. If a host receives a octet 
file and then returns it, the returned file must be identical to the 
original. Mail mode uses the name of a mail recipient in place of a 
file and must begin with a WRQ. Otherwise it is identical to netascii 
mode. The mail recipient string should be of the form "username" or 
"username@hostname". If the second form is used, it allows the option 


of mail forwarding by a relay computer. 


The discussion above assumes that both the sender and recipient are 
operating in the same mode, but there is no reason that this has to be 
the case. For example, one might build a storage server. There is no 
reason that such a machine needs to translate netascii into its own form 
of text. Rather, the sender might send files in netascii, but the 
storage server might simply store them without translation in 8-bit 
format. Another such situation is a problem that currently exists on 
DEC-20 systems. Neither netascii nor octet accesses all the bits in a 
word. One might create a special mode for such a machine which read all 
the bits in a word, but in which the receiver stored the information in 
8-bit format. When such a file is retrieved from the storage site, it 
must be restored to its original form to be useful, so the reverse mode 
must also be implemented. The user site will have to remember some 
information to achieve this. In both of these examples, the request 
packets would specify octet mode to the foreign host, but the local host 
would be in some other mode. No such machine or application specific 


modes have been specified in TFTP, but one would be compatible with this 
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specification. 


It is also possible to define other modes for cooperating pairs of 
hosts, although this must be done with care. There is no requirement 


that any other hosts implement these. There is no central authority 


that will define these modes or assign them names. 


Figure 5-2: DATA packet 


Data is actually transferred in DATA packets depicted in Figure 5-2. 
DATA packets (opcode = 3) have a block number and data field. The block 


numbers on data packets begin with one and increase by one for each new 


block of data. This restriction allows the program to use a single 
number to discriminate between new packets and duplicates. The data 
field is from zero to 512 bytes long. If it is 512 bytes long, the 
block is not the last block of data; if it is from zero to 511 bytes 
long, it signals the end of the transfer. (See the section on Normal 


Termination for details.) 


All packets other than those used for termination are acknowledged 
individually unless a timeout occurs. Sending a DATA packet is an 
acknowledgment for the ACK packet of the previous DATA packet. The WRQ 


and DATA packets are acknowledged by ACK or ERROR packets, while RRO and 
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Figure 5-3: ACK packet 


ACK packets are acknowledged by DATA or ERROR packets. Figure 5-3 
depicts an ACK packet; the opcode is 4. The block number in an ACK 
echoes the block number of the DATA packet being acknowledged. A WRQ is 
acknowledged with an ACK packet having a block number of zero. 


Figure 5-4: ERROR packet 


An ERROR packet (opcode 5) takes the form depicted in Figure 5-4. An 
ERROR packet can be the acknowledgment of any other type of packet. The 
error code is an integer indicating the nature of the error. A table of 
values and meanings is given in the appendix. (Note that several error 
codes have been added to this version of this document.) The error 
message is intended for human consumption, and should be in netascii. 


Like all other strings, it is terminated with a zero byte. 
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6. Normal Termination 

The end of a transfer is marked by a DATA packet that contains between 
0 and 511 bytes of data (i.e. Datagram length < 516). This packet is 
acknowledged by an ACK packet like all other DATA packets. The host 
acknowledging the final DATA packet may terminate its side of the 
connection on sending the final ACK. On the other hand, dallying is 
encouraged. This means that the host sending the final ACK will wait 
for a while before terminating in order to retransmit the final ACK if 
it has been lost. The acknowledger will know that the ACK has been lost 
if it receives the final DATA packet again. The host sending the last 
DATA must retransmit it until the packet is acknowledged or the sending 
host times out. If the response is an ACK, the transmission was 
completed successfully. If the sender of the data times out and is not 
prepared to retransmit any more, the transfer may still have been 
completed successfully, after which the acknowledger or network may have 
experienced a problem. It is also possible in this case that the 


transfer was unsuccessful. In any case, the connection has been closed. 


7. Premature Termination 

If a request can not be granted, or some error occurs during the 
transfer, then an ERROR packet (opcode 5) is sent. This is only a 
courtesy since it will not be retransmitted or acknowledged, so it may 


never be received. Timeouts must also be used to detect errors. 
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I. Appendix 


Order of Headers 


2 bytes 

“Local Medium | Internet | Datagram | TFTP Opcode 
TFTP Formats 
Type Op # Format without header 

2 bytes string 1 byte string 1 byte 
RRQ/ | 01/02 | Filename | 0 | Mode | 0 | 
WRQ 9 ----------------------------------------------- 

2 bytes 2 bytes n bytes 
pata | 03 | Block # | Data — 

2 bytes 2bytes 
ack | 04 | Block # | 

2 bytes 2 bytes | string 1 byte 
ERROR | 05 | ErrorCode | ErrMsg | 0 | 
\026 
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Initial Connection Protocol for reading a file 


1. Host A sends a "RRQ" to host B with source= A's TID, 
destination= 69. 


2. Host B sends a "DATA" (with block number= 1) to host A with 
source= B’s TID, destination= A’s TID. 


15 


Error Codes 


< 
w 
= 
[an 
0) 


Meaning 

Not defined, see error message (if any). 
File not found. 

Access violation. 

Disk full or allocation exceeded. 
Illegal TFTP operation. 

Unknown transfer ID. 

File already exists. 

No such user. 


YHOU BPWNEF OO 
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3 
Internet User Datagram Header [2] 


Format 


0 1 2 3 
OL 2 34567 8 901 2 34506 78 904 2 30450607 8-19 01 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Source Port | Destination Port 
SS SR SE 
| Length | Checksum | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Values of Fields 


Source Port Picked by originator of packet. 
Dest. Port Picked by destination machine (69 for RRQ or WRQ). 
Length Number of bytes in packet after Datagram header. 
4 
Checksum Reference 2 describes rules for computing checksum. 
Field contains zero if unused. 

Note: TFTP passes transfer identifiers (TID’s) to the Internet User 
Datagram protocol to be used as the source and destination ports. 

3 

This has been included only for convenience. TFTP need not be 


implemented on top of the Internet User Datagram Protocol. 

4 

The implementor of this should be sure that the correct algorithm is 
used here. 
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